本篇是故事五的「內化」篇。

本篇要回答：把「拒絕用一個 bool 說謊」落成一份可實作的非同步命令契約，長什麼樣子？

當時發生了什麼

拒絕一個需求的正確姿勢，不是只說「做不到」，而是給出「做得到的版本」。Day 24 證明了布林介面必然說謊；這一篇交出替代品——非同步命令契約：

1. 發布前建立唯一 command_id。
2. 呼叫立即回覆 accepted 與 command_id——受理是當場可以誠實承諾的最大值，不冒充執行完成。
3. 設計結果回路：結果 Topic／Channel、Callback 或狀態查詢介面，擇一或並用。
4. 所有結果事件用 command_id（或 Correlation Data）配對。
5. 狀態空間明確定義：accepted、executing、succeeded、failed、timed_out、unknown。
6. 每道命令設定合理逾時，逾時值由設備實際反應時間推導，不拍腦袋。
7. 逾時與明確失敗嚴格區分——timed_out 允許查證後改判，failed 需要失敗證據。
8. 重試必須定義冪等鍵與重複執行行為：同一 command_id 重送是補償，新 ID 是新命令，兩者的設備端語意必須先想清楚。
9. 全程事件軌跡保存（Day 22 的收據清單就是保存規格）。
10. 最終的 succeeded 由實際執行端回報或狀態對帳證明——外部效果是唯一的結案證據。

呼叫端的使用方式隨之改變：從「呼叫→拿到成敗」變成「呼叫→拿到 command_id→訂閱或輪詢結果」。同步的錯覺消失了，換來的是每個狀態都有證據背書。

我原本怎麼判斷

我曾擔心這套契約「把簡單的事搞複雜」。後來想通：複雜度從來沒有增加，它本來就在那裡——八層旅程、逾時、重試、未知狀態，一個都不會因為介面假裝簡單而消失。布林介面只是把複雜度掃進事故日的地毯下面；契約只是把它攤回桌面，逐項標價。

我怎麼查證或重現

契約的驗收方式（對照 Day 30 的改善措施標準）：正常路徑——命令走完全程，狀態依序推進且全程可用 command_id 對帳；失敗路徑——設備明確拒絕，狀態停在 failed 且附設備回應；逾時路徑——結果回路中斷時，狀態在期限後轉為 timed_out 而非 false；重複路徑——同一冪等鍵重送，設備端動作不重複執行。四條路徑都能在測試環境演練，這份契約才算存在。

區分證據等級。已確認事實：契約各條款皆為可實作、可測試的機制。合理推論：導入後事故調查時間顯著縮短——因為 Day 22 那張表的每一格都有了固定住址。執行假設：需求方接受「受理≠完成」的介面語意——這需要 Day 21 到 24 的論證當溝通材料，這個系列某種程度上就是為了那場溝通而寫的。

今天留下什麼方法

第五種失效模式

系統要求最前面那一層，替後面所有尚未發生的事情保證成功。

本篇收尾

我不是不願意回答指令成功與否；我只是拒絕在指令還走在路上時，替遠端設備簽下完工證明。

五個故事到此全部收束。最後五天（Day 26 起），把五次踩雷疊在一起看——它們其實是同一種事故的五種變形。